REMARKS 

Claims 1-9 and 11-21 remain in the application. Applicant respectfully requests that this 
amendment after final be entered on the grounds that it simplifies the issues on appeal. 

Claims 14-17 and 19-22 were rejected under 35U.S.C. § 112 as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
his invention. The Office Action specifically set out that the ambiguity between dependent 
claims 14 and 19 and their parent claim was based on the conflicting recitations of "a plurality of 
application processors and "an application processor." 

Claims 14 and 19 have been amended so that claim 14 depends from claim 1, and claim 
19 depends from claim 9 as suggested in the Office Action. Applicant respectfully requests that 
this rejection be withdrawn. 

Claims 1-9, 11-14, 18 and 19 were rejected under 35 U.S.C. § 103(a) as unpatentable 
over Travaille et al (6,067,107) in view of Agraharam et al (6,389,471), and further in view of 
Goodman et al (6,427,238). Applicant respectfully traverses. 

The Office Action combines the three prior art references of Travaille, Agraharam and 
Goodman in this rejection. Applicant respectfully submits that the combination is improper in 
that a person of ordinary skill in this art, when called upon to modify Travaille, a reference that 
relates to interactive applications following the disclosure of Agraharam, would not produce the 
claimed invention. 

Claim 1 is directed to a method of delivering an interactive application. This method 
includes the step of providing a set of application components. An example of application 
components is set out in Claim 1 1 as executable program files, bit maps, sound samples, real- 
time data instructions, and video chips. These application components enable a remote 
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participant in the interactive application to interact locally so that potentially each individual 
viewer will see different on-screen information. For example, each viewer may have a different 
score in an interactive quiz or navigate to a different part of the appHcation, unrelated to where 
the other viewers or participants are. 

Agraharam teaches a system wherein information is presented to all users at the same 
time. All changes to the presentation occur at the broadcast controller. Therefore, the same 
change to every viewer's screen is affected at the same time. Agraharam, in column 3, lines 
7-12, discloses that information is presented in HTML as standard, but where this is not possible, 
the presentation is converted to an MPEG2 stream, i.e., a digital audio-visual stream. This 
conversion is essentially the same as filming the screen of a PC monitor displaying the HTML 
presentation and broadcasting it as a digital TV channel. In other words, what is broadcast is no 
longer an application made up of separate multi-media components (graphics, sound samples, bit 
maps, etc.), but rather is a basic AV broadcast akin to a TV channel. 

The bottom line, Agraharam is not suitable for broadcasting sets of application 
components of an interactive application. It does not teach that. It cannot be relied on to modify 
Travaille to do so. 

With respect to claim 2, the Office Action seems to assert that Agraharam teaches that 
when the users of the client terminals enter a private or public chat room, that his information is 
then rebroadcast to the client terminals in real time. Applicant respectfully traverses. 

The chat rooms of Agraharam operate in the normal fashion of a chat room with the 
session conductor being one of the participants. Obviously the ongoing chat may influence the 
conductor's presentation, but there is no evidence that the actual chat data is broadcast to the 
client terminals. Column 1, lines 9-11, of Agraharam states: 
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"... to a system which allows a user to prepare and broadcast 
information over the internet to an audience of individuals 
simultaneously." 

It should also be noted that while data may be broadcast simultaneously, there is no provision in 
Agraharam that data is received simultaneously by the remote participants. 

With respect to claim 4, the Office Action asserts that Agraharam teaches the step of 
converting which includes adapting for different data transmission mechanisms. A conversion in 
Agraharam is only true in a sense that the HTML data is converted to a video signal in much the 
same way as a video capture card or a TV camera operates. This is hardly the same as 
converting interactive applications, component by component, to execute on receivers which 
have different capabilities. Furthermore, converting data into a format that is compatible with a 
broadcast receiver, as described in column 4, hnes 41-49, of Agraharam , is hardly the 
conversion of the present invention. The disclosure of Agraharam does not discuss the 
simultaneous data insertion of an interactive application into multiple channels from the same 
broadcast. Furthermore, it should be remembered that the Internet is under totally different 
technical constraints than is ITV (interactive TV). It is these constraints which are also 
addressed by the present invention, for example, ITV requires transmission and substitution on 
the fly in order for remote participants to receive the interactive application at substantially the 
same time. Agraharam can only replace or select an entire application and transcode it in its 
entirety to an MPEG2 format. This is described in column 6, lines 49-52, of Agraharam. If the 
broadcast receivers do not have HTML processing capabilities, the controller (303) directs the 
broadcast interface (308) to transcode the data signals from HTML format into MPEG2 before 
transmission to the broadcast receivers. This is an all or nothing process for simply distributing 
mark-up language documents through the Internet. 
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With respect to claim 7, the Office Action asserts that Agraharam teaches the "target 
platform" in claim 7. Applicant respectfully traverses. The receiver of Agraharam is not an 
application process. It may simply be an MPEG video decoder (see column 2, lines 10-11, and 
column 3, lines 7-12). 

With respect to claim 8, the Office Action asserts ihai Agraharam teaches a system which 
interrogates the application processor. Applicant respectfully traverses. Agraharam only really 
describes determining whether the terminal has data processing capabilities or not. In other 
words, can it process HTML? If not, then it assumes that it can process MPEG2 video. This is 
much less sophisticated than determining what the application processor is capable of in terms of 
memory, graphics, sound, etc., and converting it accordingly. 

Applicant respectfully requests that the rejection of claims 1-9, 11-14, 18 and 19 be 
withdrawn, and the claims allowed. 

Claims 15-17, 20-22 were rejected under 35 U.S.C. § 103 as unpatentable over Travaille 
(6,067,107) in view of Agraharam (6,389,471) and Goodman (6,427,238), and further in view of 
Lappington et al (5,764,275). Applicant respectfully traverses. 

The Office Action asserts that Lappington teaches compensation for timing differences 
between broadcast networks, referring to column 3, starting at line 19. Applicant respectfully 
submits that the Office Action is incorrect in its analysis of this passage. This passage deals with 
differences between transmission times at the local client terminal rather than attempting to 
synchronize broadcast data at each application processor. There is no indication in Lappington 
that there is an attempt to synchronize broadcast data at each processor. While the interactive 
data could be designed and synchronized to a specific frame, it is not disclosed by Lappington 
that this is synchronized at each application interface on the basis that the head end must 
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synchronize to the particular television signal. Accordingly, Lappington does not teach 
synchronization to an independent network synchronized signal. 

The purpose of Lappington is to detect the artificial insertion of a time delay at some 
point in the broadcast chain to prevent the remote participant from cheating. It seems to be 
assumed that such a delay would only be introduced in the vicinity of the client terminal by the 
home user, although it is possible that delays could be introduced elsewhere. It is notable that 
the transmission time does not vary at the local client terminal (since the transmission is central), 
but the reception time may vary if artificial delays are inserted by recording the broadcast and 
then replaying it, for example. Lappington does not describe any method for synchronization. It 
simply detects when data has been unduly delayed and takes appropriate corrective action, such 
as disallowing the scoring of points for that question, or the entire event. 

Applicant respectfully requests that the rejection of claims 15-17, 20-22 be withdrawn 
and the claims allowed. 
/// 
/// 
/// 
/// 
/// 
/// 
/// 
/// 
/// 
/// 
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In light of the above amendment and remarks, apphcant beUeves that all the claims are 
allowable, and respectfully requests that this amendment be entered, all the claims allowed, and 
the application passed to issue. 
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